FB - Preco vynechava Foreign key pri optimalizacii
Otázka od: Roland Turcan
12. 9. 2004 22:38
Hello All!
Snazim sa zoptimalizovat prikaz:
select a.jedin,b.jedin
from na_vedomie a
left join dokumenty b on b.jedin=a.dokument
where b.spis=13308;
skusil som aj takto
select a.jedin,b.jedin
from dokumenty b
right join na_vedomie a on a.dokument=b.jedin
where b.spis=13308;
a v oboch pripadoch mi vrati zly cas a plan vypada takto:
PLAN JOIN (A NATURAL,B INDEX (RDB$PRIMARY54))
pritom tie stlpce JEDIN v oboch tabulkach su primarne kluce a
NA_VEDOMIE.DOKUMENT obsahuje Foreign key na DOKUMENTY.JEDIN a napriek
tomu optimalizator kasle na neho.
Skusal som rovnaku konstrukciu k inymi tabulkami:
select a.jedin,b.jedin
from ukony a
left join adresar b on b.jedin=a.adresar
WHERE A.SPIS=13308;
kde tiez obe tabulky maju JEDIN ako primarne kluce a UKONY.ADRESAR ma
Foreign key na ADRESAR.JEDIN a exekucny plan je nasledovny:
PLAN JOIN (A INDEX (FK_UKONY_SPIS),B INDEX (RDB$PRIMARY3))
Kde sa stala chyba?
--
Best regards, TRoland
http://www.rotursoft.sk
http://exekutor.rotursoft.sk
Odpovedá: Karel Rys
13. 9. 2004 6:32
Ahoj,
v tom druhem dotazu, co davas jako priklad, vyhledavas podle a.spis. Neslo by
ten prvni,
problemovy, dotaz prepsat tak, abys tam mel "from dokumenty b"...
"where b.spis="...."? Tj. udelat
to propojeni opacne. Pokud mas dokumenty.spis i na_vedomie.dokument indexovano, melo by to pak jit
rychle.
Karel Rys
Roland Turcan dne 12 Sep 2004 v 23:38:
> Hello All!
>
> Snazim sa zoptimalizovat prikaz:
>
> select a.jedin,b.jedin
> from na_vedomie a
> left join dokumenty b on b.jedin=a.dokument
> where b.spis=13308;
>
> skusil som aj takto
>
> select a.jedin,b.jedin
> from dokumenty b
> right join na_vedomie a on a.dokument=b.jedin
> where b.spis=13308;
>
> a v oboch pripadoch mi vrati zly cas a plan vypada takto:
> PLAN JOIN (A NATURAL,B INDEX (RDB$PRIMARY54))
>
> pritom tie stlpce JEDIN v oboch tabulkach su primarne kluce a
> NA_VEDOMIE.DOKUMENT obsahuje Foreign key na DOKUMENTY.JEDIN a napriek
> tomu optimalizator kasle na neho.
>
> Skusal som rovnaku konstrukciu k inymi tabulkami:
>
> select a.jedin,b.jedin
> from ukony a
> left join adresar b on b.jedin=a.adresar
> WHERE A.SPIS=13308;
>
> kde tiez obe tabulky maju JEDIN ako primarne kluce a UKONY.ADRESAR ma
> Foreign key na ADRESAR.JEDIN a exekucny plan je nasledovny:
>
> PLAN JOIN (A INDEX (FK_UKONY_SPIS),B INDEX (RDB$PRIMARY3))
>
> Kde sa stala chyba?
> --
> Best regards, TRoland
> http://www.rotursoft.sk
> http://exekutor.rotursoft.sk
>
>
>
Odpovedá: Roland Turcan
13. 9. 2004 6:40
KR> Roland Turcan dne 12 Sep 2004 v 23:38:
>> Hello All!
>>
>> Snazim sa zoptimalizovat prikaz:
>>
>> select a.jedin,b.jedin
>> from na_vedomie a
>> left join dokumenty b on b.jedin=a.dokument
>> where b.spis=13308;
>>
>> skusil som aj takto
>>
>> select a.jedin,b.jedin
>> from dokumenty b
>> right join na_vedomie a on a.dokument=b.jedin
>> where b.spis=13308;
>>
>> a v oboch pripadoch mi vrati zly cas a plan vypada takto:
>> PLAN JOIN (A NATURAL,B INDEX (RDB$PRIMARY54))
>>
>> pritom tie stlpce JEDIN v oboch tabulkach su primarne kluce a
>> NA_VEDOMIE.DOKUMENT obsahuje Foreign key na DOKUMENTY.JEDIN a napriek
>> tomu optimalizator kasle na neho.
>>
>> Skusal som rovnaku konstrukciu k inymi tabulkami:
>>
>> select a.jedin,b.jedin
>> from ukony a
>> left join adresar b on b.jedin=a.adresar
>> WHERE A.SPIS=13308;
>>
>> kde tiez obe tabulky maju JEDIN ako primarne kluce a UKONY.ADRESAR ma
>> Foreign key na ADRESAR.JEDIN a exekucny plan je nasledovny:
>>
>> PLAN JOIN (A INDEX (FK_UKONY_SPIS),B INDEX (RDB$PRIMARY3))
>>
>> Kde sa stala chyba?
<<< 13.9.2004 7:38 - Karel Rys "delphi@zas-me.cz" >>>
KR> v tom druhem dotazu, co davas jako priklad, vyhledavas podle a.spis. Neslo
by ten prvni,
KR> problemovy, dotaz prepsat tak, abys tam mel "from dokumenty
KR> b"...
"where b.spis="...."? Tj. udelat
KR> to propojeni opacne. Pokud mas dokumenty.spis i
KR> na_vedomie.dokument indexovano, melo by to pak jit
KR> rychle.
To ze v druhom pouzivam a.spis nie je v tomto momente dolezite, lebo
je dotaz identicky s druhym prikladom. A ide len o to ze na
UKONY.ADRESAR pouzil FK a v pripade NA_VEDOMIE.DOKUMENT nie.
--
Best regards, TRoland
http://www.rotursoft.sk
http://exekutor.rotursoft.sk
Odpovedá: Karel Rys
13. 9. 2004 7:12
Roland Turcan dne 13 Sep 2004 v 7:40:
> To ze v druhom pouzivam a.spis nie je v tomto momente dolezite, lebo
> je dotaz identicky s druhym prikladom. A ide len o to ze na
> UKONY.ADRESAR pouzil FK a v pripade NA_VEDOMIE.DOKUMENT nie.
Nejsou identicke, v jednom mas left join, ve druhem right join, ne?
Jak dopadne tohle:
select a.jedin,b.jedin
from dokumenty b
left outer join na_vedomie a on a.dokument=b.jedin
where b.spis=13308;
Karel Rys
Odpovedá: Lebeda David
13. 9. 2004 7:04
> Snazim sa zoptimalizovat prikaz:
>
> select a.jedin,b.jedin
> from na_vedomie a
> left join dokumenty b on b.jedin=a.dokument
> where b.spis=13308;
>
> skusil som aj takto
>
> select a.jedin,b.jedin
> from dokumenty b
> right join na_vedomie a on a.dokument=b.jedin
> where b.spis=13308;
> pritom tie stlpce JEDIN v oboch tabulkach su primarne kluce a
> NA_VEDOMIE.DOKUMENT obsahuje Foreign key na DOKUMENTY.JEDIN a napriek
> tomu optimalizator kasle na neho.
Ahoj,
ja spis postradam index na sloupci b.spis, ktery je ve where, nebot to podle me
vede k
nutnosti natural scanu. No a v pripade indexu na b.spis by melo byt rychlejsi,
kdyz bude
tabulka b ve from nez jako prijoinovana - tedy aspon timto smerem bych se
ubiral ja.
David Lebeda
Odpovedá: Roland Turcan
13. 9. 2004 7:14
<<< 13.9.2004 8:13 - Karel Rys "delphi@zas-me.cz" >>>
KR> Roland Turcan dne 13 Sep 2004 v 7:40:
>> To ze v druhom pouzivam a.spis nie je v tomto momente dolezite, lebo
>> je dotaz identicky s druhym prikladom. A ide len o to ze na
>> UKONY.ADRESAR pouzil FK a v pripade NA_VEDOMIE.DOKUMENT nie.
KR> Nejsou identicke, v jednom mas left join, ve druhem right join, ne?
Ano, ja truba mas svatu pravdu.
KR> Jak dopadne tohle:
KR> select a.jedin,b.jedin
KR> from dokumenty b
KR> left outer join na_vedomie a on a.dokument=b.jedin
KR> where b.spis=13308;
Toto je to prave orechove.
Dakujem.
--
Best regards, TRoland
http://www.rotursoft.sk
http://exekutor.rotursoft.sk